home *** CD-ROM | disk | FTP | other *** search
/ NOVA - For the NeXT Workstation / NOVA - For the NeXT Workstation.iso / Newsletters / GEnieUnixNews / unxnl-04.91 < prev    next >
Text File  |  1992-12-27  |  22KB  |  470 lines
  1.  
  2.           _ __  _   _ __ _ __
  3.          // /  //| // || \\|     N E W S
  4.         //_/  // |//  ||  |\\    Vol 2, Issue 2 - April 1991
  5.          R o u n d T a b l e
  6.  
  7.    Items of interest to participants of the GEnie Unix RoundTable
  8.  
  9.       The RoundTable SysOps are:
  10.       Dave Weinstein......OLORIN     Brian Riley.........DELPHI
  11.       Gary Smith..........GARS       Chris North-Keys....HARP
  12.       Rick Mobley.........LRARK    All Unix SysOps.....UNIXSYSOPS$
  13.    We strongly encourage you to contact any or all of us if you have -ANY-
  14.  comments or suggestions. This is -YOUR- RoundTable. We are here to make
  15.  your participation as pleasant and beneficial as possible.
  16.  
  17.  ED: editor notes - request repeated.
  18.  --
  19.    One among us is not very persuasive. In the last newsletter I issued a 
  20.  call for recommendations of groups and organizations that might provide a
  21.  synergistic addition to the GEnie Unix RoundTable. 'C' Users Group was
  22.  offered as an example. They are actually an excellent model. C is the
  23.  companion language of Unix, so there would be an interest among our user
  24.  base, yet this group could not be reasonably expected to support an entire
  25.  RoundTable on their own. The obvious solution would be a dedicated self-
  26.  managed Category here in the Unix RoundTable, subject only to the rules
  27.  and regulations imposed by GEnie.
  28.   
  29.    Either none among you can think of a single prospect, or I failed to
  30.  convince you of our sincere desire to enhance this area in such a manner.
  31.  I will assume for the moment I am just a lousey salesman, and this time
  32.  I will plead for input. Please e-mail your suggestions for prospective
  33.  alliances to UNIXSYSOPS$.    P L E A S E  !
  34.   Thanks, Gary
  35.  
  36.  GUI Article 
  37.  -----------
  38.      by Dave Weinstein (OLORIN)
  39.  
  40.  Graphical User Interfaces (the G standing for other things depending on how
  41.  long I've been trying to get a bug out of a project). Now one of the hottest
  42.  buzz-words to strike the community in years.
  43.  
  44.  And, surprisingly, most of the hype is reasonably accurate. Customers _do_
  45.  want the windows and scroll bars and buttons and mice. And with more than
  46.  a million copies of MicroSoft Windows 3.0 sold, they'll be getting them
  47.  in large numbers.
  48.  
  49.  Right. So what does all this have to do with Unix anyway? Well, X runs
  50.  under NeXT Step. X runs under Windows 3.0. A/UX plugs into the Maxc
  51.  toolkit. Windows and windowing systems are becoming standard on Unix
  52.  boxes of all shapes and colors. But, since character based applications
  53.  do run as windows under most of the various windowing systems, is it worth
  54.  the enormously higher development time and cost for putting together a
  55.  windowed application?
  56.  
  57.  It probably is. For one thing, that cost is going down, as more and more
  58.  skilled programmers become familiar with GUIs and the paradigm shifts
  59.  involved in programming, the cost of hiring one (or for that matter finding
  60.  one) should go down. Moreover, new generations of tools are coming out,
  61.  several libraries have been released which allow code to be written which
  62.  will run (with little or no modification, at least theoretically) under
  63.  X, Windows 3.0, the Macintosh, the NeXT. This brings the cost of development
  64.  down dramatically because the expense is paid only once for multiple
  65.  platforms. But most importantly, windowed applications are an important
  66.  asset in selling a product. Many potential clients are at least familiar
  67.  with Windows or the Mac interface, many prefer them. And being able to
  68.  provide that sort of an interface, even if there are few differences
  69.  between the "GUI User Frueiendly Fifth Generation BuzzWord Overload" version
  70.  and the character based version, will make more people willing to look
  71.  at the product you sell, and even more willing to buy.
  72.  
  73.  --Dave
  74.       
  75.  SECURITY :
  76.  --------
  77.    
  78.  The following is a security checklist for users of Ultrix (tm) that
  79.  appeared as a sidebar to an article on security in the April 1991
  80.  issue of "DEC PROFESSIONAL" authored by Philip E. Bourne, Ph. D.,
  81.  and Janie Weiss. It is reproduced here by permission of Professional
  82.  Press, 101 Winner Road, Horsham, PA 19044. Permission granted by Lou
  83.  Pilla, Managing Editor. contents copyright 1991 Professional Press.
  84.   
  85.  While some items on this list are Ultrix specific, the vast majority
  86.  apply to any Unix platform.  Gary (GARS)
  87.   
  88.  - The following suggestions, aimed at users, can provide security for
  89.    an individual's files:
  90.  [] Don't run other users' programs unless you own them.
  91.  [] Don't run programs from unknown sources.
  92.  [] Avoid "dumb" passwords.
  93.  [] Maintain correct file and directory protections.
  94.  [] Use file encryption for sensitive files.
  95.  [] Periodically monitor files for problem signs.
  96.  [] Take special care of hidden files, e.g.  .profile,  .cshrc and  
  97.     .netrc.
  98.      
  99.  - The following suggetions, aimed at the system administrator, can provide 
  100.    security for the entire system:
  101.     
  102.  [X] General Security...
  103.  [] Don't ever run a user-owned program as "root".
  104.  [] Don't put current directory first in PATH list, especially for "root".
  105.  [] Invoke 'su' only when absolutely necessary, and then use the absolute
  106.     pathname /bin/su.
  107.  [] Make sure /usr/adm/sulog is 600 mode and owned by "root".
  108.  [] Be wary of software from an unknown source.
  109.  [] Run auditing.
  110.  [] Use the trusted path feature.
  111.       
  112.  [X] Account Security...
  113.  [] Develop a password policy and distribute it to all users.
  114.  [] Always use 'edpath' and 'vipw'.
  115.  [] Use 'chsh' and 'chfn' whenever possible.
  116.  [] Avoid defining captive accounts.
  117.  [] Turn on accounting.
  118.  [] Use UPGRADE or ENHANCED security levels. Otherwise:
  119.   1. Remove all "idle" guest accounts.
  120.   2. Remove all null password fields.
  121.   3. Don't allow group accounts.
  122.   4. Implement password controls, e.g., aging, maximum and minimum length.
  123.   
  124.  [X] Network Security...
  125.  [] Be sure /etc/hosts.equiv contains only local hosts and no "+".
  126.  [] Be sure /etc/hosts contains no "+".
  127.  [] Decide whether .rhosts files are permitted.
  128.  [] Include only local hosts in the "root" .rhosts file.
  129.  [] Have only "console" lebeled as "secure" in /etc/ttys (servers only).
  130.  [] Don't export NFS filesystems to the world.
  131.  [] Don't include a "decode" alias in the aliases file.
  132.  [] Don't have a "wizzard" password in sendmail.cf.
  133.  [] Don't have a "debug" command in sendmail.
  134.  [] Be sure modems and terminal servers handle hangups correctly.
  135.  [] Control LAT usage.
  136.  [] Pay special attention to UUCP, tip and cu.
  137.  [] For DECnet ULTRIX, consider whether to have the "guest" account.
  138.  [] Decide whether to support anonymous FTP.
  139.      
  140.  [X] DECwindows Security... 
  141.  [] Control who can access your display.
  142.  [] Consider using secure keyboard mode.
  143.  [] Software-lock your workstation when it is unattended.
  144.   
  145.  [X] Filesystem Security...
  146.  [] Check protections and ownership of all system files.
  147.  [] Don't permit 'setuid' or 'setgid' shell scripts.
  148.  [] Check all "nonstandard" 'setuid' or 'setgid' programs for security.
  149.  [] Remove 'setuid' bit from /usr/etc/restore.
  150.  [] Don't have the sticky bits set on world-writable directories.
  151.  [] Have the proper 'unmask' value on the "root" account.
  152.  [] Have correct protection modes on devices in /dev.
  153.  [] Be wary of users bearing private filesystems.
  154.   
  155.  [X] Backups...
  156.  [] Take level 0 dumps at least monthly.
  157.  [] Take incremental dumps at least biweekly.
  158.  [] Be careful of ownership of restored files.
  159.  
  160.   FAST and NASTY, DOWN  and  DIRTY:  quick  fix scripts that do something
  161.  --------------------------------
  162.             by Gary (GARS)  
  163.  Here are some insider tips on how to create BASIC-like for/next loops
  164.  using Korn and Bourne shells:
  165.  
  166.  In article <robtu.670879801@mexia> robtu@itx.isc.com (Rob Tulloh) writes:
  167.  >In the version of ksh running on the RS/6000, the following is possible:
  168.  >
  169.  >typeset -i FILES=10
  170.  >while [ $i -gt 0 ] ; do
  171.  >    # body of loop
  172.  >    FILES=FILES-1
  173.  >done
  174.  >
  175.  >The typeset -i forces FILES to be interpreted as an integer and allows
  176.  >you to forgo the use of $var and the let syntax.
  177.               
  178.  In fact,  my ksh  comes with an exported alias for typeset -i
  179.  named "integer"
  180.  
  181.  So I can say:
  182.  
  183.   integer FILES=10
  184.  -- 
  185.  Art Kamlet  a_s_kamlet@att.com  AT&T Bell Laboratories, Columbus
  186.      
  187.    
  188.  In an article, ux.acs.umn.edu!edh (Merlinus Ambrosius) writes:
  189.  >In sh, I'd like to do something like a BASIC for loop.  Say I have $FILES
  190.  >set to some number, and I'd like to go through a loop $FILES times.  Can
  191.  >this be done in sh?
  192.    
  193.  count=10
  194.  i=0
  195.  
  196.  while [ $i -lt $count ]
  197.  do
  198.         i=`expr $i + 1`
  199.         echo "This is iteration $i"
  200.  done
  201.  -- 
  202.  Michael Stefanik, MGI Inc, Los Angeles | Opinions stated are never realistic
  203.  Title of the week: Systems Engineer    | UUCP: ...!uunet!bria!mike
  204.  ----------------------------------------------------------------------------
  205.  If MS-DOS didn't exist, who would UNIX programmers have to make fun of?
  206.  
  207.  Tips from Group Talisman
  208.  ------------------------
  209.  (a.k.a. strange things to do with Unix when you're bored.)
  210.               by: Christopher A. North keys (HARP)
  211.  
  212.  Part I:  A Csh alias for safer removes.
  213.  
  214.  There are several distinctive things about this particular alias.  Firstly,
  215.  if this alias is named so as to override the standard `rm' command,
  216.  it is still far safer than aliasing `rm' to `rm -i', because it
  217.  encourages use of pattern matching, and discourages running `rm *' by
  218.  default and depending on its asking y/n for each file.  Secondly, this
  219.  alias is far less irritating than `rm -r'-style aliases, in that a single
  220.  y/n answer is sufficient, where 20 or 30 might have been required using -i.
  221.  Lastly, if you discover the hard way one day that the alias was *missing*
  222.  when you did your `rm' command, at least you would have picked up the habit
  223.  of using the right file-matching patterns before, and the raw `rm' command
  224.  was still have done only what you desired.
  225.  
  226.  Note that if you call this command something besides `rm', and if your
  227.  search path is set with the `.' *after* directories like /bin and /usr/bin,
  228.  then `ls' and `rm' are sufficient command names within the alias.  If
  229.  there is *any* chance of their getting masked by other aliases or by
  230.  commands in the current directory, then use full pathnames.
  231.  
  232.  alias r '/bin/ls -FCA \!*; echo -n 'remove?';
  233.                                      if ("$<" == "y") /bin/rm -r \!*'
  234.  
  235.  Part II:  Avoiding core dumps in particular directories.
  236.  
  237.  Core dumps are files written out by Unix when a program detonates in a
  238.  particularly ugly manner.  These files are invaluable for debugging,
  239.  especially if the program had been compiled with debugging symbols
  240.  included, as in `cc -g -o program program.c'.  A debugging session can
  241.  be started with a command like `dbx program core', where core is the
  242.  traditional name of the core dump left by your program.
  243.  
  244.  A core dump contains just about everything that was part of the program
  245.  when it was running.  All the code, values of variables, what part was
  246.  executing, the stack, etc.  Once, while using a GNU Emacs to edit a
  247.  paper I was helping my sister write, the network began thrashing in a
  248.  really *big* way, eventually causing the Emacs to core dump while trying
  249.  to write out the file we were working on (it takes a lot to get an Emacs
  250.  to crash and dump core...).  After the network recovered, we use a new
  251.  Emacs to edit the core dump of the last one, found the section in the
  252.  core where the file we'd been editing was, and saved the text out to
  253.  disk.  Useful.
  254.  
  255.  The problem with core dumps is that they can be really huge, like eight
  256.  megabytes or more on some systems, and it follows that you might not
  257.  always want to let programs dump themselves into your user space when
  258.  they have a problem.
  259.  
  260.  The usual solution is to set `ulimit coredumpsize 0' (in csh) or its
  261.  equivalent.  This indicates that no core dumps are allowed.  Problem:
  262.  what if you only want to prevent core dumps in a particular directory,
  263.  say you home directory?
  264.  
  265.          ln -s /dev/null core
  266.  
  267.  Any core dump into this directory will be redirected by the symlink to
  268.  /dev/null, never to be seen again.
  269.  However, if you're in a subdirectory working on a new program, the core
  270.  dumps you will probably want to use are still allowed and available.
  271.  
  272.  -Christopher Alex.
  273.  
  274.  BUILDING your PLATFORM:
  275.  ----------------------     
  276.  
  277.  CONFIGURATION ( fellow SysOp Brian Riley (delphi) continues his discussion
  278.        on how to customize the U/A on a Unix system using a 3b1 as his model)
  279.        
  280.        * editor's note: part 1 of this series is available in UNXNL-10.90
  281.                  part 2 is available in UNXNL-01.91. Both newsletters are
  282.                  posted in library 1 of the GEnie Unix RT software libraries.
  283.                               ---------------
  284.                    Customizing the User Agent (tm)
  285.                          on the Unix Pc (tm)
  286.                       by Brian T. Riley (DELPHI)
  287.                                Part 3
  288.  
  289.      Lets start this time with the login option. There is a little
  290.      known ( and little used ) feature of the "login" program that
  291.      allows us to do fancy things in our .profile when we log in. The
  292.      Login program has the capabilaty to expand the environment two
  293.      ways when a person logs in. The first is in the form of "Var=value"
  294.      such as TERM=vt100. This allows users who log in at different
  295.      terminals to specify their terminal type when they log in. This
  296.      works fine on most Unix systems, however the Unix-pc is a little
  297.      different since it prompts the user for a terminal type, therefore,
  298.      it is not usefull to us. The second method is very usefull to us
  299.      and much easier to use. The second method  states that any values
  300.      specified after the login name (but not in the form of "Var=value")
  301.      will be assigned to a variable of the form "Lx" where x starts
  302.      with 0 and is incremented when annother is needed. As an example,
  303.      suppose we did this;
  304.  
  305.  Login: brian u <ret>
  306.  
  307.  then in our .profile we did this;
  308.  
  309.  LOGINVAR=$L0
  310.  echo "LOGINVAR=$LOGINVAR"
  311.  
  312.  This is what would happen;
  313.  
  314.  Login: brian u <ret>
  315.  Password:
  316.  
  317.  LOGINVAR=u
  318.  $
  319.  
  320.      Now that we know how it works, lets make it work for us. The standard
  321.      .profile for the Unix-pc contains the following entry;
  322.  
  323.  #sccs     "@(#)install:.profile    1.3"
  324.  
  325.  if [ "$SHFLAG" != 1 ]
  326.  then
  327.           exec /usr/bin/ua
  328.  fi
  329.  
  330.      Lets make a simple change to this if - then statement that makes it a
  331.      little more flexable.
  332.  
  333.  #sccs     "@(#)install:.profile    1.3"
  334.  
  335.  if [ "$L0" != "u" ]
  336.  then
  337.           exec /usr/bin/ua
  338.  fi
  339.  
  340.      This now gives us a choice when we log in to run the UA or not
  341.      just by placing a "u" after our login name. This feature can be
  342.      very usefull, and is limited only by our imagination and our
  343.      shell programming ability.
  344.  
  345.      Next, we will explore some of the more usefull features of the
  346.      Korn Shell. The Korn Shell (ksh) was written by David Korn at
  347.      Bell Laboratories to add capabilities similar to the C-Shell
  348.      while maintaining compatability with the Bourne Shell. Among
  349.      the features is added capability to the "set" command. Some of
  350.      these are shown below.
  351.  
  352.  -a     All export.   Any variable set will be exported automatically.
  353.  -o x   option        Specify options such as command line editing mode
  354.                      ( vi, emacs, gmacs)
  355.  
  356.      These two options give us a lot of capability in a minimum of
  357.      programming . By entering the next line at the beginning of our
  358.      .profile;
  359.  
  360.  set -ao vi
  361.  
  362.      any variables we set in the .profile or from the command line will
  363.      automatically be exported to the system environment and we will have
  364.      command line editing using "vi" syntax. Now, lets explore this
  365.      "command line editing" a little more. How many times have you been
  366.      typing in a long and complex command sequence and realized that you
  367.      miss-spelled one of the earlier commands at the beginning of the line?
  368.      If you're like me, once is too many times! Well , with the Korn shell
  369.      you don't have to start over, you just press escape and use the line
  370.      editing commands of vi to go back and correct it., then go back to the
  371.      end of the line and continue on!!! ( this assumes you are useing the
  372.      vi mode for command line editing) Annother nice feature of ksh is
  373.      command recall, this means that commands that you have already executed
  374.      can be brought back and edited or just re-executed. This feature is
  375.      also controlled by the editor mode you have chosen. Vi mode uses "j"
  376.      to go forward in the list and "k" to go backwards. You must press
  377.      escape first to get into line editing mode. Two variables control
  378.      command history. They are "HISTFILE" and "HISTSIZE". HISTFILE
  379.      should be set to the name of the file that will hold the
  380.      previously executed commands. HISTSIZE is set to the number of
  381.      previously executed commands that are available to this shell,
  382.      the default is 128. My .profile has the following entries;
  383.  
  384.  #sccs     "@(#)install:.profile    1.3"
  385.  
  386.  set -amh -o vi
  387.  umask 000
  388.  VISUAL=/usr/bin/vi
  389.  PCOMM=$HOME/Pcomm
  390.  ROGUEOPTS="name=Delphi"
  391.  ENV=$HOME/.ksh.hist
  392.  HISTSIZE=24
  393.  > $HISTFILE
  394.  
  395.  
  396.  if [ "$L0" != "u" ]
  397.  then
  398.           exec /usr/bin/ua
  399.  fi
  400.  
  401.      We will explore more features of the Korn Shell next time,and I
  402.      will explain the other entries in my .profile, but see if you
  403.      can figure them out in the mean time. :)
  404.  
  405.      Now we will find out why Installable files are so usefull and how
  406.      they work. An installable file is actually a cpio archive
  407.      containing all of the files required to install a package on the
  408.      Unix-pc or create an installable disk. It requires certain files
  409.      to be present in a specific order  at the beginning of the
  410.      archive. These are;
  411.  
  412.  Size    -    This contains a number representing the total size of all
  413.               files in the File.
  414.  Name    -    This contains the name of the package that will be used
  415.               in the Installed Package list of the UA.
  416.  Remove  -    This contains the shell script needed to remove the package.
  417.  Install -    This contains the script needed to install the package.
  418.  Files   -    This contains a list of all files in the package in the
  419.               correct order.
  420.  
  421.      The rest of the files in the package are added after these files
  422.      in the order specified in the Files file. All path names are
  423.      relative to the current directory. ( I.E. no "/" at the beginning
  424.      of the path name). To install a package you must select
  425.      Administration, then Software Setup, then Install Software sent
  426.      by Electronic Mail. The first thing that happens is the file is
  427.      copied to a newly created directory - /tmp/installed , and then
  428.      extracted. Your system is then checked to see if there is enough
  429.      space to install it. If so you are given the option of creating a
  430.      backup of the package on an installable floppy. You must have a
  431.      formatted floppy or the script will fail. Next the Install script
  432.      from the package is executed and the package is installed.
  433.      Finally the name of the package is added to the Uninstall menu,
  434.      the UA is updated and the original files and the /tmp/installed
  435.      directory are removed. Note that the original Installable file is
  436.      also removed so you can't just uninstal t and start over! The
  437.      best way to learn about Installable files is to download one from
  438.      the Library section of the Unix-Rt and take it apart. Just search
  439.      the library for files with the keyword 3b1 or unixpc and look for
  440.      files with a +IN in the name. Don't forget to uncompress it
  441.      before you try to install it. Till next time, Have fun with the
  442.      3B1. :)
  443.  
  444.      Brian T. Riley
  445.      Delphi@UnixRt
  446.      brian@jerimy.snide.com
  447.  ---------------    
  448.     REMINDER - This newsletter is being sent to you 'by request'. If you do
  449.  not wish to keep receiving it, e-mail a stop notice to GARS. On the other
  450.  hand, we would very much appreciate it if you would pass the word that we
  451.  do distribute this item near the tenth (10th) of the month of issue to any-
  452.  one on GEnie who requests it, and will gladly add any name that is requested
  453.  via the same route... e-mail to GARS.
  454.    P L E A S E  also remember contributions are most welcome. Please e-mail
  455.  items and/or suggestions to GARS.
  456.  
  457.  (EOF)
  458.  
  459.  Trademark and Copyright notices:
  460.  Unix is a Trademark of  AT&T; GEnie, LiveWire, and RoundTable are Trademarks
  461.  of General Electric Information Services  Company;  Xenix is a Trademark  of
  462.  Microsoft  Corporation; DEC Professional is a Trademark of Professional Press,
  463.  Mac, MacIntosh and A/UX are Trademarks of Apple Computer, NeXt and NeXt Step,
  464.  are Trademarks of NeXt, Inc., Windows 3.0 is a proprietary user interface of
  465.  Microsoft Corporation, C Users Group is a Trademark of R&D Publications, Inc.
  466.    
  467. The contents of this newsletter are copyright (c) 1991 and may be copied whole
  468. or in part only if  original  credit is included. The GEnie UNIX RoundTable is
  469. not affiliated with AT&T.
  470. ay be copied whole